IBIS Macromodel Task Group

Meeting date: 11 August 2015

Members (asterisk for those attending):
ANSYS:                      * Dan Dvorscak
                            * Curtis Clark
Avago (LSI)                   Xingdong Dai
                              Bob Miller
Cadence Design Systems:     * Ambrish Varma
                              Brad Brim
                              Kumar Keshavan
                              Ken Willis
eASIC                       * David Banas
                              Marc Kowalski
Ericsson:                     Anders Ekholm
IBM                           Steve Parker
Intel:                        Michael Mirmak
Keysight Technologies:      * Fangyi Rao
                            * Radek Biernacki
                              Nicholas Tzou
Maxim Integrated Products:    Hassan Rafat
Mentor Graphics:            * John Angulo
                            * Arpad Muranyi
Micron Technology:          * Randy Wolff
                              Justin Butterfield
QLogic Corp.                  James Zhou
                              Andy Joy
SiSoft:                     * Walter Katz
                            * Todd Westerhoff
                            * Mike LaBonte
Synopsys                      Rita Horner
Teraspeed Consulting Group:   Scott McMorrow
Teraspeed Labs:             * Bob Ross
TI:                           Alfred Chong

(Note: Agilent has changed to Keysight)

The meeting was led by Arpad Muranyi.

------------------------------------------------------------------------
Opens:

- Curtis stated that he would not be able to attend the following meeting.
  Arpad said he would therefore be asking for a volunteer to take minutes.
  Randy said that he thought he would be available to take the minutes.
--------------------------
Call for patent disclosure:

- None
-------------
Review of ARs:

- None
-------------------------
Review of Meeting Minutes:

- Arpad: Does anyone have any comments or corrections? [none]
- Curtis: I received no feedback via email for last week's minutes.
- Mike L.: Motion to approve the minutes.
- Arpad: Second.
- Arpad: Anyone opposed?  [none]

-------------
New Discussion:
- Arpad: We had an email last week regarding the Backchannel issue.
- Walter: I sent a private email to Ambrish, Radek and Arpad.
  - I stated that I do not want to continue working on perfecting a Backchannel
    BIRD.
  - We don't see sufficient interest from IC vendors and customers.
  - I've done significant work on this.
  - I think my proposal is a good approach.
  - I'm going to step back and let Ambrish and others come up with a new BIRD
    that meets the fundamental requirements in a way they feel comfortable with.
- Ambrish: [summarizing discussions with Walter, et al.]
  - Simplify BIRD 147 to remove any complications with the stimulus of the
    back channel interface file.  Generally what Walter's proposal did.
  - Also propose a simple Tx BCI file that will cover most current transmitters.
    - Analogous to Walter's second "pigeon" proposal.
  - Will also allow for any future BCI file that someone may want to propose.
  - Maintaining the position that the EDA tool will not have any involvement
    with the message other than passing it back and forth. 
  - With these changes we will then reintroduce BIRD 147 to the ATM.
- Arpad: Based on this discussion I will remove item #11 (SiSoft co-optimization
         proposal) from our tabled topics list.
- Walter: Yes.
- Arpad: Item #12, BIRD 147 will be untabled when Ambrish is ready to update us.

Item #7: Info, Out, InOut BIRD draft.
- Arpad: We had a good discussion last week.
  - We ended with the suggestion that people come up with ideas on how the goals
    of this proposal should be implemented in the spec.
- Walter: What are the goals?  What is the intent?
- Arpad: I made a statement that the goal was to prevent the specification from
         undermining itself by allowing undocumented non-portable features.
- Ambrish: The main goal is to somehow prevent a Model Specific parameter from
           influencing what the EDA tool does.
  - There is a lack of knowledge about what the tool would need to do.
- Walter: So, "A model maker should not expect the EDA tool to do anything
          differently based upon the value of any Model Specific parameter."
- Ambrish: Yes.
- Walter: That's a fair statement.  That's a simple statement.
  - I'm comfortable with that.
- Radek: I believe the discussion went a bit further.
  - We generally agreed that some experimentation being done with Model Specific
    parameters is okay.
  - But, it's important that the user is aware that some EDA tools may be doing
    something specific.
- Ambrish: You could make another section or branch for EDA specific parameters.
  - Once you put a Model Specific parameter in the model, then users expect all
    tools to read it and handle it the same way.  That causes problems.
- Walter: "The user shall not expect that the EDA tool will do anything
           differently based on the value of a Model Specific parameter."
  - But the user can still direct the EDA tool use a certain Model Specific
    parameter's value in a certain way.  That's not a problem.
- Discussion: Walter, Todd, John, Arpad and Ambrish all showed interest in the
  proposal for a separate top level branch for experimental, non-portable
  parameters.  Fangyi and Bob did not support the idea.  They felt that nothing
  was to be gained by the added complication.  Both felt the existing Model
  Specific concept could be used for experimental parameters.  Fangyi felt the
  committee was trying to place certain restrictions on the experimental phase.
  John replied that the top level branch would really only serve to document
  the experimental nature of the parameters to the EDA tool.  Supporters felt
  the top level branch provided the flexibility and the documentation.  Arpad
  and Ambrish suggested that using Model Specific parameters for experimental,
  tool-specific features was overloading the Model Specific concept and causing
  confusion for users.  Mike L. pointed out that using normal Model Specific
  parameters for experimental features could result in EDA tools reading them
  and presenting them to users to make choices that might be unexpected.
  A suggestion was made for locating EDA tool specific branches underneath the
  Model Specific branch.  Walter preferred the top level experimental branch
  concept because it minimizes the changes necessary if a parameter is later
  accepted as a Reserved parameter.
- Arpad: [responding to objections to the new branch proposal]
  - We have come full circle now.
  - If you're saying we don't need a new branch, that's fine.
  - But now we need to go back and define explicit rules and regulations
    spelling out what the expectations are.
- Todd: At the end of the day you have to do it one way or the other.
  - How much is about expectation, and how much is about notification?
- John: If notification is the goal, that's hard to accomplish using Model
        Specific.
  - How do we achieve this goal?
- Arpad: Now is a good stopping point.
  - Thank you all for joining.

-------------
Next meeting: 18 August 2015 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
